Okay, maybe not. But it worked when I tried it manually?

The difference here is that when resolving manually it went via artifactory, while building from the lock files goes to anaconda.org.

But then how did it work from Firefox.

It works on GitHub Actions resolving from the same lockfiles, so unless GitHub have overwritten the DNS location of anaconda.org, we should be trying the same request.

Other .conda files can be downloaded from anaconda.org, including eccodes releases. Eccodes does seem particularity slow however. I suspect it is exceeding the 60 second timeout.

Theory

Something is funky about the eccodes package on anaconda.org, causing the anaconda.org server to have to do a bunch of work to retrieve it. This work takes longer than 60 seconds, so the HTTP timeout on conda times out, and the package fails to download. Artificatory is not affected as it will have its own backing store.

Actions

• Try installing with increased timeout (how?)
• Investigate what is different with eccodes. The CSET package is much faster to start downloading.
• If we discover something, report upstream to conda-forge.

Installing with increased timeout

As best as I can tell the timeout is hardcoded. I guess we could hack our conda install just to test? Or see if mamba or pixi give more options.
https://github.com/conda/conda/blob/main/conda/base/context.py#L353

I think this is a web proxy issue, and I've opened INC000263814 to try and get some logs from there.

To work around this issue the conda timeout can be increased:

conda config --set remote_read_timeout_secs 1000